用微信扫码二维码

分享至好友和朋友圈

一、背景

1. 祖传代码不敢随意改动，影响范围无法评估。并且组内时常有因为修改了某块代码，导致其他业务受到影响，产生bug，影响生产。

2. 研发提测完成后，进入测试后经常会向研发询问本次需求改动影响范围，以此来确定测试用例，以达到精准测试，提升整个需求的质量，缩短交付周期。

那么，如何才能规避这种隐患？有没有一种工具能够协助代码研发及review人员更加精确的判断当前代码改动影响范围，有没有一种方法能够提供除了业务逻辑条件验证，针对代码作用范围，给测试人员提供精确验证链路？

二、方案调研

技术方案调研

经过各方资料查找及比对，最终我们整理了两个满足我们需求的方案：

1. IDEA提供了显示调用指定Java方法向上的完整调用链的功能，可以通过“Navigate -> Call Hierarchy”菜单(快捷键：control+option+H)使用，缺点是并没有向下的调用链生成。

2. 开源框架调研：wala/soot静态代码分析工具。

针对上述的调研，大致确认了两种方案，集中分析两种方案的优劣，来制定符合我们目前情况的方案：

经过前期的比较以及相关工具的资料调研、工具功能分析，并考虑到后期一些个性化功能定制开发，以上工具不太满足我们目前的需求，所以决定自己动手，丰衣足食，尝试重新开发一个能够满足我们需求的工具，来协助研发以及测试人员。

三、方案制定

预期：工具尽量满足全自动化，研发只需要接入即可，减少研发参与，提升整个调用链展示和测试的效率。并且调用链路应该在研发打包的过程中触发，然后将数据上传至服务端，生成调用链路图。

上述方案制定完成后，需要进一步确认实现步骤。前期我们确认了工具的大概方向，并进行步骤分解，根据具体的功能将整个工具拆分成六个步骤：

1. 确认修改代码位置（行号）。与git代码管理关联，能够使用git命令，去提取研发最近一次提交代码的有变动的代码行数。

2. 根据步骤1确认收集到影响的类+方法名+类变量。

3. 根据2中确认的类+方法名称生成向上和向上的调用链。包括jar/aar包。

4. 根据3中生成的调用链完成流程图的展示。

5. 自定义注释标签Tag说明当前业务，并提取Tag内容。

6. 本地数据生成并上传服务端生成调用流程图。

整体流程图如下：

四、方案实施

1

定位源代码修改位置行号

首先我们使用 git diff --unified=0 --diff-filter=d HEAD~1 HEAD命令 输出最近一次提交修改的内容，且已知git diff 会按照固定格式输出。

通过提交增、删、改的修改，执行git diff命令，对输出内容进行观察。

举例：某次提交修改了两个文件，如下

RecommendVideoManager.java

ScrollDispatchHelper.java

git diff命令执行后，输出以下内容：

技术方案：

a. 按行读取输出内容，读取到diff 行，则识别为一个新的文件，并用正则表达式提取文件名 ：

b. 用正则表达式提取 ，用来解析代码修改行数：

c. 针对我们的需求，我们只关心本次修改影响的是哪个方法，不关心具体影响了哪些行数，所以我们只需要

就拿到了本次修改，修改开始的代码行数，在结合ASM就可以获取到本次改动影响的具体方法。

2

利用获取的行号定位具体的方法

根据上述1步骤中定位出研发每次提交修改的Java源文件和改动的行号位置，我们需要定位修改代码行号所归属的方法名称，再由方法名称+类名+包名去定位本次修改的影响链路。

如何去定位？

首先确定的是，研发在工程中只能修改的是工程中的源文件，所以我们可以在遍历收集整个工程的源文件的过程中根据已知的修改行号来确定修改的方法名称，进而知道整个方法的调用链路。而对于那些没有落到方法体范围之内的行号，基本上可以确认为类变量或常量，考虑到对于常量修改也可能影响到业务逻辑，所以我们也会对修改的Field进行上下调用的范围的查找，所以需要记录。所以整个过程分成两个部分：

a. 遍历源码Class文件，获取整个类的Field；

b. 遍历Class文件的过程中，通过visitMethod遍历整个方法体，记录方法的初始行号和结束行号，来定位方法；

首先是a部分，确认Field，ClassVisitor提供现成的方法：

所以我们可以在文件中直接获得整个类的Field。然后去根据行数去判断是否有对Fields有修改。如果Fields有修改，那么我们可以根据上述方法去比对，那么就可以获得哪个Field被修改。

接下来是b部分，在遍历Class文件的过程中，通过visitMethod方法，重写AdviceAdapter类来提供MethodVisitor，在遍历过程中，确定研发修改影响的类及方法，具体实现可分为以下步骤：

2.1 获取源文件编译好的Class文件

apk的编译过程中有很多的task需要执行，各个任务环环相扣有序的执行，我们要获取编译好的Class文件，需要在特定的任务之间。我们知道在Java Compiler之后，不管是R.java抑或是aidl，再或者是Java interfaces都会编译成.class文件，在编译完成后会接着完成dex的编译，所以我们尽可能的在dex编译之前完成class文件的处理，这种仅仅是考虑到宿主或者单独的插件工程方案，但是对于主站业务来说，会有各种各样的组件aar，aar的编译不会走dex编译，所以针对这些组件工程，我们也需要考虑到，简单的方式就是我们去监听aar编译的task，然后再做一些处理，所以在Plugin的apply方法中需要进行区分处理，代码如下：

两者的处理逻辑一致，也就是在Task的监听有些区别，所以下面我们不重复复述，以MethodTransform为主线进行讲解。

那么有的同学就会问了，为什么我们不直接对源文件.java文件进行处理呢？

因为，就目前京东主站项目而言，各个aar模块相互调用，如果我们仅仅使用源文件进行扫描，各个aar或者jar包的调用链会断掉不全面，影响代码review人员及测试人员的测试用例完整度。

接下来是代码实现，我们监听任务执行，并针对需要监听的任务开展我们的Class收集操作：

2.2 排除非class文件的干扰，对源文件路径进行递归遍历

代码的编译长短对研发的影响很大，所以编译时长很宝贵，需要我们尽量的减少编译的时长，所以我们在执行自定义的Transform过程中，需要过滤并排除非Class文件，减少不必要的浪费。经过整理主要为：R文件以及R文件的内部类R$*文件，包括R$string、R$styleable等等，所以，在遍历处理过程中我们需要对R文件及R$*文件过滤。

2.3 提供ClassVisitor类和MethodClass去搜集Class及对应Method，并定位

这个步骤是最主要的一部分，这一部分主要获取两部分数据，第一部分是研发修改直接影响到的类和方法；第二部分是遍历整个源文件的所获得的类信息，主要包括类+各个方法以及各个方法体，也就是方法中的指令；

在拿到transformInvocation后我们进行源文件文件夹遍历和所有jar包的遍历，在外层我们定义好存储被影响的类列表（changedClassesList），和包含类信息的列表（classesInfoList），将两个列表作为参数，传递进去在遍历过程中赋值。这里值得注意的是，在进行jar解析过程中不需要进行changedClassesList，因为对于本工程来说研发人员不会直接对jar文件中文件操作。

在对源文件遍历过程中，我们进行定位搜寻。

遍历源文件根节点并读取：

重写ClassVisitor，ASM提供的visit方法可以很方便的去识别这个类的各种信息，而我们用到的信息为两种，一种是接口类型的判定，一种是当前类的类名。对于接口，我们没有必要去进行Method的访问，对获得的类名信息我们进行判定当前类是否是git最后提交有做过修改的类：

在上述的visit中我们定位了当前类是否与上次git提交的是否有关，接下来我们需要MethodVisitor中进行有选择的拦截对应的Method的访问。

重写MethodVisitor在visitMethod中进行拦截处理，如果git修改相关在当前类中，则我们在访问Method时，进行方法体行数定位。

在MethodVisitor中，我们可以通过系统方法定位访问方法的每条方法指令及指令对应的行数，所以我们只要重写visitLineNumber方法即可实时的在visitMethodInsn方法中拿到方法体访问行数，这里有个小的注意点就是，我们在调用visitLineNumber返回的line不是我们理解意义上的方法名称部分开始，而是从方法体的第一行代码计算开始，所以我们在做判断的时候，需要注意，相对方法体的首行，我们更关心方法体的变更，所以我们只需要判定落在visitMethodInsn中的更改即可。有需要更加精细的判定，小伙伴可以进行更加精细的调研。

以下是visitLineNumber方法：

知道了方法体开始的地方，我们也需要知道结束的位置，获取到结束位置后，我们就能轻松的定位到我们需要定位的方法体，从而获得方法名称，进一步获得类的名称。ASM在MethodVisitor中提供了visitEnd方法，表示方法体访问结束，那么我们就可以在visitEnd中进行定位：

既然自带的工具可以完成Java文件注释的提取，那么我们也可以在代码中获取到对应的注释，经过相关资料了解到JDK中自带的tools.jar包可以完成JavaDoc的提取。

在将tools包上传Maven后在gradle中进行依赖，基本就完成了环境的配置。经过多方资料的查找及demo实验，tools包支持命令的形式生JavaDoc。这里需要注意的是，我们不需要html形式的javadoc文档形式，所以需要进行一些自定义的东西来达到我们自己的要求。

官方文档是这样说的：

If you run javadoc without the -doclet command-line option, it will default to the standard doclet to produce HTML-format API documentation.

也就是说，我们需要在命令行中添加-doclet来进行自定义文档。并且给出自定义的Doclet类：

接下来简单的封装tools中的execute方法：

其中命令中参数，感兴趣的小伙伴可以查看官方文档，这里就不再赘述了。

基本封装完成后，就可以直接使用了，但是考虑到在遍历使用的过程中会出现多次调用解析ClassDoc的问题，这里还是建议将解析过的Java文件进行缓存处理，方便直接调用，也能减少整个编译的时间，并且在解析过程中我们也需要排除系统类的解析。

这里我们也给出自定义Tag，当然，在项目中可以根据自己的业务名称进行命名。

完成了功能的开发，我们需要在代码中进行验证，测试如下：

当我们的方法调用链涉及到getPrintMethod()时，就会提取@LogicIntroduce标签后面的内容，达到了获取业务逻辑说明注释的目的。这样对于那些不懂代码的非研发人员，也能够非常清晰的看懂这部分代码涉及到的业务逻辑，测试也能够着重的进行测试了。

本地输出：

5

推荐实际业务使用

方法的调用上下链路在上述步骤中已经生成，我们可以在MarkDown中简单的生成调用链，至于要遵循什么样的格式，大家可以自己查阅，相对比较简单不再展开。下面是推荐位最近一次修改涉及到的部分流程图：

代码修改位置输出为：

向上调用链展示：

向下调用链，我们只取本方法体：

相关Javadoc输出：

五、总结

经过上面的描述，我们整体上完成了在Android端的代码影响范围工具探索，过程中完成了Git定位，生成方法调用的上、下链路，以及通过JDK工具jar包完成注释以及自定义Tag的内容获取，也通过MarkDown生成了对应的流程图。下面是整个工程的流程说明图：

对于这个工具来说，我们仅仅是对Android客户端的探索开发，目前已在推荐组进行试用，使用过程中还有一些问题以及流程需要进一步改善和优化，比如，当一个方法被多处调用则生成的关系图就会过去庞大，不容易被阅读；无法突出调用链节点的一些关键节点；JavaDoc强依赖于研发，如果注释不规范或者不写，那整个链路的说明就会断掉等等，我们会持续性的去优化打磨这个工具，也会在使用过程中添加一些更贴近业务的功能，或者调整部分流程，比如说会在本地编译触发或者手动触发，或者添加一些JavaDoc的模板等等。这些功能会在业务使用过程中进行调整。后续也会在服务端铺开，逐步拓展业务面，为我们的业务开发交付降本增效。

参考文档：

https://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/doclet/overview.html

https://git-scm.com/docs/git-diff

聊聊企业开源的底层逻辑

特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.